Architectures such as that provided by Universal Plug and Play (UPnP™) define architectures for the network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. The goal of UPnP™ technology is to provide easy-to-use, flexible, standards-based connectivity for ad-hoc or unmanaged networks whether in a home, in a small business, or in public spaces. In support of this goal, UPnP™ supports zero-configuration, “invisible” networking, and the automatic discovery of devices from a wide range of manufacturers. As a result, a device can dynamically join a network, obtain an IP address, convey its capabilities to the network, and determine the presence and capabilities of other devices.
UPnP™ is more particularly an open networking architecture that consists of services, devices, and control points. Control points are essentially software applications and are the active components of the UPnP™ architecture. Devices are physical or logical entities, enumerated via simple extensible Markup Language (XML) descriptions and containing Application Programming Interfaces (APIs) referred to as services. Physical devices may host multiple logical devices, and each device may host multiple services. Services are groups of states and actions. For example, a light switch has an “on” state and an “off” state. An action allows the network to determine the state of the switch or to change the state of the switch. Services typically reside in devices.
One of the primary concerns with emerging connectivity architectures is that of quality of service (QoS). Currently, UPnP™ defines a framework intended to improve the user experience of a network's ability to deliver predictable results for sensitive applications such as audio, video, and voice applications. For more information on such a framework, see UPnP Forum, UPnP QoS Architecture 1.0 (Mar. 10, 2005), the content of which is incorporated herein in its entirety.
Although UPnP™ currently defines a framework for ensuring a desired level of QoS, the QoS framework generally fails for remote nodes accessing a UPnP™ network. Conventionally, remote nodes accessing a UPnP™ network typically do so via a Virtual Private Network (VPN) or other secure tunnel (e.g., IPSec, SSL/TLS, etc.) in such a manner that the remote nodes appear to correspondent nodes within the UPnP™ network as though they are part of the UPnP™ network. A fundamental assumption for UPnP™ QoS is that every device in the UPnP™ network is in the same IP subnet, and as such, routing between devices in UPnP™ is out of scope for UPnP™ QoS. That is, although the remote device is part of the same IP subnet as the UPnP™ network, the segment between the remote device and an Internet Gateway Device (IGD) (providing access to the UPnP™ network) is inside a VPN tunnel. Thus, conventional UPnP™ QoS may fail to work via a VPN or other secure tunnel as the QoS signaling is buried in the VPN or other secure tunnel and not visible to the network elements necessary to establish that QoS.